Skip to content

Retire the mcp:Access action - #1344

Closed
jiaenren wants to merge 1 commit into
jiaenr/mcp-resolve-signing-keyfrom
jiaenr/mcp-retire-access-action
Closed

Retire the mcp:Access action#1344
jiaenren wants to merge 1 commit into
jiaenr/mcp-resolve-signing-keyfrom
jiaenr/mcp-retire-access-action

Conversation

@jiaenren

@jiaenren jiaenren commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

Stacked on #1343. Retires an RBAC action that is never evaluated.

Issue #None

+2 / -100.

Why

mcp:Access mapped to exactly one path, /mcp, and ext_authz is disabled on that route, so it was never evaluated. A role granting it implied an access control that did not run, which is worse than not having the action at all.

The wholesale gate is the identity-provider scope: JWTVerifier rejects a token without it, so a caller cannot reach the protocol endpoint. Per-operation authorization is unchanged, because every tool call reaches OSMO through /api, where gateway JWT validation and semantic RBAC apply exactly as they do for the CLI and UI.

resourceTypeMCP and ResourceTypeMCP go with it; nothing outside the registry referenced either. The two removed tests existed only to assert this action's path mapping.

No migration needed

IsValidAction has no callers, so nothing validates stored role actions against the registry. A role row still granting mcp:Access simply keeps an action matching no path, which is already the case today since the route bypasses ext_authz. Removing it from the seeded default role means the grant stops being handed out; it does not need clearing from existing rows.

Verification

  • bazel test //src/utils/roles/... passes 2/2, including the integration test
  • bazel test //src/utils/connectors/tests:test_default_roles passes
  • render-tests.sh passes

Left alone

deployments/charts/osmo/tests/control-mcp-values.yaml also contains the string mcp:Access, but under scopes:. That is an OAuth scope in the direct-mode fixture, a different concept that happens to share the spelling. It belongs with the direct-mode removal, not here.

🤖 Generated with Claude Code

@jiaenren
jiaenren requested a review from a team as a code owner August 27, 2026 23:31
@coderabbitai

coderabbitai Bot commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 1eface0f-aeb6-4818-8b6c-2f34bb2d0636

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

@jiaenren
jiaenren force-pushed the jiaenr/mcp-resolve-signing-key branch from 53f3e6d to 3540fc9 Compare August 27, 2026 23:37
@jiaenren
jiaenren force-pushed the jiaenr/mcp-retire-access-action branch from c320243 to f8942b2 Compare August 27, 2026 23:37
The action mapped to exactly one path, /mcp, and ext_authz is disabled
on that route, so it was never evaluated. A role granting it therefore
implied an access control that did not run -- worse than not having the
action at all.

The wholesale gate is the identity-provider scope: JWTVerifier rejects a
token without it, so a caller cannot reach the protocol endpoint at all.
Per-operation authorization is unchanged, because every tool call
reaches OSMO through /api where gateway JWT validation and semantic RBAC
apply exactly as they do for the CLI and UI.

resourceTypeMCP and ResourceTypeMCP go too; nothing outside the registry
referenced either. The two tests removed existed only to assert this
action's path mapping.

Existing deployments need no migration. IsValidAction has no callers, so
nothing validates stored role actions against the registry: a role row
still granting mcp:Access keeps an action that matches no path, which is
already true today.
@jiaenren

Copy link
Copy Markdown
Collaborator Author

Consolidated into #1342 to reduce the number of PRs in this stack for review.

Retiring mcp:Access removes another thing a deployment had to declare that never took effect.

No content is lost: the cumulative diff of the stack against main is byte-identical to before the consolidation (verified by comparing the resulting tree). Closing this one.

@jiaenren jiaenren closed this Aug 28, 2026
@jiaenren
jiaenren deleted the jiaenr/mcp-retire-access-action branch August 31, 2026 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant